CAS Configuration Storage
Various properties can be specified in CAS either inside configuration files or as command line switches. This section provides a list common CAS properties and references to the underlying modules that consume them.
This section outlines strategies that can be used to store CAS configuration and settings.
Standalone
This is the default configuration mode which indicates that CAS does NOT require connections to an external configuration server and will run in an embedded standalone mode.
The following settings and properties are available from the CAS configuration catalog:
cas.standalone.configuration-directory=
Describes a directory path where CAS configuration may be found. |
cas.standalone.configuration-file=
Describes a file path where that contains the CAS properties in a single file. |
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
By Directory
CAS by default will attempt to locate settings and properties inside a given directory and otherwise falls back to using:
/etc/cas/config/opt/cas/config/var/cas/config
CAS has the ability to also load a Groovy file for loading settings. The file
is expected to be found at the above matching
directory and should be named ${cas-application-name}.groovy, such as cas.groovy. The
script is able to combine conditional settings for active profiles and common settings
that are applicable to all environments and profiles into one location with a
structure that is similar to the below example:
1
2
3
4
5
6
7
8
9
// Settings may be filtered by individual profiles
profiles {
standalone {
cas.some.setting="value"
}
}
// This applies to all profiles and environments
cas.common.setting="value"
By File
You can also use a dedicated configuration file to directly feed a collection of properties to CAS in form of a file or classpath resource. This is specially useful in cases where a bare CAS server is deployed in the cloud without the extra ceremony of a configuration server or an external directory for that matter and the deployer wishes to avoid overriding embedded configuration files.
Spring Cloud
The following settings are to be loaded by the CAS configuration runtime, which bootstraps
the entire CAS running context. They are to be put inside the src/main/resources/bootstrap.properties
of the configuration server itself. See this guide for more info.
The configuration server backed by Spring Cloud supports the following profiles.
Native
Load settings from external properties/yaml configuration files.
The following settings and properties are available from the CAS configuration catalog:
spring.cloud.config.server.native.add-label-locations=true
Flag to determine whether label locations should be added. |
spring.cloud.config.server.native.default-label=master
|
spring.cloud.config.server.native.fail-on-error=false
Flag to determine how to handle exceptions during decryption (default false). |
spring.cloud.config.server.native.order=
|
spring.cloud.config.server.native.search-locations=
Locations to search for configuration files. Defaults to the same as a Spring Boot app so [classpath:/,classpath:/config/,file:./,file:./config/]. |
spring.cloud.config.server.native.version=
Version string to be reported for native repository. |
spring.profiles.active=
Comma-separated list of active profiles. Can be overridden by a command line switch. |
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
Git Repository
Allow the CAS Spring Cloud configuration server to load settings from an internal/external Git repository. This then allows CAS to become a client of the configuration server, consuming settings over HTTP where needed.
The following settings and properties are available from the CAS configuration catalog:
spring.cloud.config.server.git.basedir=
Base directory for local working copy of repository. |
spring.cloud.config.server.git.clone-on-start=false
Flag to indicate that the repository should be cloned on startup (not on demand). Generally leads to slower startup but faster first query. |
spring.cloud.config.server.git.clone-submodules=false
Flag to indicate that the submodules in the repository should be cloned. |
spring.cloud.config.server.git.default-label=
The default label to be used with the remote repository. |
spring.cloud.config.server.git.delete-untracked-branches=false
Flag to indicate that the branch should be deleted locally if it's origin tracked branch was removed. |
spring.cloud.config.server.git.force-pull=false
Flag to indicate that the repository should force pull. If true discard any local changes and take from remote repository. |
spring.cloud.config.server.git.host-key=
Valid SSH host key. Must be set if hostKeyAlgorithm is also set. |
spring.cloud.config.server.git.host-key-algorithm=
One of ssh-dss, ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, or ecdsa-sha2-nistp521. Must be set if hostKey is also set. |
spring.cloud.config.server.git.ignore-local-ssh-settings=false
If true, use property-based instead of file-based SSH config. |
spring.cloud.config.server.git.known-hosts-file=
Location of custom .known_hosts file. |
spring.cloud.config.server.git.order=
The order of the environment repository. |
spring.cloud.config.server.git.passphrase=
Passphrase for unlocking your ssh private key. |
spring.cloud.config.server.git.password=
Password for authentication with remote repository. |
spring.cloud.config.server.git.preferred-authentications=
Override server authentication method order. This should allow for evading login prompts if server has keyboard-interactive authentication before the publickey method. |
spring.cloud.config.server.git.private-key=
Valid SSH private key. Must be set if ignoreLocalSshSettings is true and Git URI is SSH format. |
spring.cloud.config.server.git.proxy=
HTTP proxy configuration. |
spring.cloud.config.server.git.refresh-rate=0
Time (in seconds) between refresh of the git repository. |
spring.cloud.config.server.git.repos=
Map of repository identifier to location and other properties. |
spring.cloud.config.server.git.search-paths=
Search paths to use within local working copy. By default searches only the root. |
spring.cloud.config.server.git.skip-ssl-validation=false
Flag to indicate that SSL certificate validation should be bypassed when communicating with a repository served over an HTTPS connection. |
spring.cloud.config.server.git.strict-host-key-checking=true
If false, ignore errors with host key. |
spring.cloud.config.server.git.timeout=5
Timeout (in seconds) for obtaining HTTP or SSH connection (if applicable), defaults to 5 seconds. |
spring.cloud.config.server.git.uri=
URI of remote repository. |
spring.cloud.config.server.git.username=
Username for authentication with remote repository. |
spring.profiles.active=
Comma-separated list of active profiles. Can be overridden by a command line switch. |
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
The above configuration also applies to online git-based repositories such as Github, BitBucket, etc.
Consul
Allow the CAS Spring Cloud configuration server to load settings from HashiCorp’s Consul.
The following settings and properties are available from the CAS configuration catalog:
spring.cloud.consul.config.acl-token=
|
spring.cloud.consul.config.data-key=data
If format is Format.PROPERTIES or Format.YAML then the following field is used as key to look up consul for configuration. |
spring.cloud.consul.config.default-context=application
|
spring.cloud.consul.config.enabled=true
|
spring.cloud.consul.config.fail-fast=true
Throw exceptions during config lookup if true, otherwise, log warnings. |
spring.cloud.consul.config.format=
|
spring.cloud.consul.config.name=
Alternative to spring.application.name to use in looking up values in consul KV. |
spring.cloud.consul.config.prefix=
Deprecation status is |
spring.cloud.consul.config.prefixes=
|
spring.cloud.consul.config.profile-separator=,
|
spring.cloud.consul.config.watch.delay=1000
The value of the fixed delay for the watch in millis. Defaults to 1000. |
spring.cloud.consul.config.watch.enabled=true
If the watch is enabled. Defaults to true. |
spring.cloud.consul.config.watch.wait-time=55
The number of seconds to wait (or block) for watch query, defaults to 55. Needs to be less than default ConsulClient (defaults to 60). To increase ConsulClient timeout create a ConsulClient bean with a custom ConsulRawClient with a custom HttpClient. |
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
Vault
Allow the CAS Spring Cloud configuration server to load settings from HashiCorp’s Vault.
The following settings and properties are available from the CAS configuration catalog:
spring.cloud.vault.app-id.app-id-path=app-id
Mount path of the AppId authentication backend. |
spring.cloud.vault.app-id.network-interface=
Network interface hint for the "MAC_ADDRESS" UserId mechanism. |
spring.cloud.vault.app-id.user-id=MAC_ADDRESS
UserId mechanism. Can be either "MAC_ADDRESS", "IP_ADDRESS", a string or a class name. |
spring.cloud.vault.app-role.app-role-path=approle
Mount path of the AppRole authentication backend. |
spring.cloud.vault.app-role.role=
Name of the role, optional, used for pull-mode. |
spring.cloud.vault.app-role.role-id=
The RoleId. |
spring.cloud.vault.app-role.secret-id=
The SecretId. |
spring.cloud.vault.application-name=application
Application name for AppId authentication. |
spring.cloud.vault.authentication=
|
spring.cloud.vault.aws-ec2.aws-ec2-path=aws-ec2
Mount path of the AWS-EC2 authentication backend. |
spring.cloud.vault.aws-ec2.identity-document=http://169.254.169.254/latest/dynamic/instance-identity/pkcs7
URL of the AWS-EC2 PKCS7 identity document. |
spring.cloud.vault.aws-ec2.nonce=
Nonce used for AWS-EC2 authentication. An empty nonce defaults to nonce generation. |
spring.cloud.vault.aws-ec2.role=
Name of the role, optional. |
spring.cloud.vault.aws-iam.aws-path=aws
Mount path of the AWS authentication backend. |
spring.cloud.vault.aws-iam.endpoint-uri=
STS server URI. @since 2.2 |
spring.cloud.vault.aws-iam.role=
Name of the role, optional. Defaults to the friendly IAM name if not set. |
spring.cloud.vault.aws-iam.server-name=
Name of the server used to set |
spring.cloud.vault.azure-msi.azure-path=azure
Mount path of the Azure MSI authentication backend. |
spring.cloud.vault.azure-msi.identity-token-service=
Identity token service URI. @since 3.0 |
spring.cloud.vault.azure-msi.metadata-service=
Instance metadata service URI. @since 3.0 |
spring.cloud.vault.azure-msi.role=
Name of the role. |
spring.cloud.vault.config.lifecycle.enabled=true
Enable lifecycle management. |
spring.cloud.vault.config.lifecycle.expiry-threshold=
The expiry threshold. |
spring.cloud.vault.config.lifecycle.lease-endpoints=
Set the |
spring.cloud.vault.config.lifecycle.min-renewal=
The time period that is at least required before renewing a lease. @since 2.2 |
spring.cloud.vault.config.order=0
Used to set a Deprecation status is |
spring.cloud.vault.connection-timeout=5000
Connection timeout. |
spring.cloud.vault.discovery.enabled=false
Flag to indicate that Vault server discovery is enabled (vault server URL will be looked up via discovery). |
spring.cloud.vault.discovery.service-id=vault
Service id to locate Vault. |
spring.cloud.vault.enabled=true
Enable Vault config server. |
spring.cloud.vault.fail-fast=false
Fail fast if data cannot be obtained from Vault. |
spring.cloud.vault.gcp-gce.gcp-path=gcp
Mount path of the Kubernetes authentication backend. |
spring.cloud.vault.gcp-gce.role=
Name of the role against which the login is being attempted. |
spring.cloud.vault.gcp-gce.service-account=
Optional service account id. Using the default id if left unconfigured. |
spring.cloud.vault.gcp-iam.credentials.encoded-key=
The base64 encoded contents of an OAuth2 account private key in JSON format. |
spring.cloud.vault.gcp-iam.credentials.location=
Location of the OAuth2 credentials private key. Since this is a Resource, the private key can be in a multitude of locations, such as a local file system, classpath, URL, etc. |
spring.cloud.vault.gcp-iam.gcp-path=gcp
Mount path of the Kubernetes authentication backend. |
spring.cloud.vault.gcp-iam.jwt-validity=15m
Validity of the JWT token. |
spring.cloud.vault.gcp-iam.project-id=
Overrides the GCP project Id. |
spring.cloud.vault.gcp-iam.role=
Name of the role against which the login is being attempted. |
spring.cloud.vault.gcp-iam.service-account-id=
Overrides the GCP service account Id. |
spring.cloud.vault.host=localhost
Vault server host. |
spring.cloud.vault.kubernetes.kubernetes-path=kubernetes
Mount path of the Kubernetes authentication backend. |
spring.cloud.vault.kubernetes.role=
Name of the role against which the login is being attempted. |
spring.cloud.vault.kubernetes.service-account-token-file=/var/run/secrets/kubernetes.io/serviceaccount/token
Path to the service account token file. |
spring.cloud.vault.kv.application-name=application
Application name to be used for the context. |
spring.cloud.vault.kv.backend=secret
Name of the default backend. |
spring.cloud.vault.kv.backend-version=2
Key-Value backend version. Currently supported versions are:
Deprecation status is |
spring.cloud.vault.kv.default-context=application
Name of the default context. |
spring.cloud.vault.kv.enabled=true
Enable the kev-value backend. |
spring.cloud.vault.kv.profile-separator=/
Profile-separator to combine application name and profile. |
spring.cloud.vault.kv.profiles=
List of active profiles. @since 3.0 |
spring.cloud.vault.namespace=
Vault namespace (requires Vault Enterprise). |
spring.cloud.vault.pcf.instance-certificate=
Path to the instance certificate (PEM). Defaults to |
spring.cloud.vault.pcf.instance-key=
Path to the instance key (PEM). Defaults to |
spring.cloud.vault.pcf.pcf-path=pcf
Mount path of the Kubernetes authentication backend. |
spring.cloud.vault.pcf.role=
Name of the role against which the login is being attempted. |
spring.cloud.vault.port=8200
Vault server port. |
spring.cloud.vault.read-timeout=15000
Read timeout. |
spring.cloud.vault.scheme=https
Protocol scheme. Can be either "http" or "https". |
spring.cloud.vault.session.lifecycle.enabled=true
Enable session lifecycle management. |
spring.cloud.vault.session.lifecycle.expiry-threshold=7s
The expiry threshold for a |
spring.cloud.vault.session.lifecycle.refresh-before-expiry=5s
The time period that is at least required before renewing the |
spring.cloud.vault.ssl.cert-auth-path=cert
Mount path of the TLS cert authentication backend. |
spring.cloud.vault.ssl.enabled-cipher-suites=
List of enabled SSL/TLS cipher suites. @since 3.0.2 |
spring.cloud.vault.ssl.enabled-protocols=
List of enabled SSL/TLS protocol. @since 3.0.2 |
spring.cloud.vault.ssl.key-store=
Trust store that holds certificates and private keys. |
spring.cloud.vault.ssl.key-store-password=
Password used to access the key store. |
spring.cloud.vault.ssl.key-store-type=
Type of the key store. @since 3.0 |
spring.cloud.vault.ssl.trust-store=
Trust store that holds SSL certificates. |
spring.cloud.vault.ssl.trust-store-password=
Password used to access the trust store. |
spring.cloud.vault.ssl.trust-store-type=
Type of the trust store. @since 3.0 |
spring.cloud.vault.token=
Static vault token. Required if |
spring.cloud.vault.uri=
Vault URI. Can be set with scheme, host and port. |
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
Token Authentication
Tokens are the core method for authentication within Vault. Token authentication requires a static token to be provided.
The following settings and properties are available from the CAS configuration catalog:
spring.cloud.vault.authentication=
|
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
AppID Authentication
Vault supports AppId authentication that consists of two hard to guess
tokens. The AppId defaults to spring.application.name that is statically
configured. The second token is the UserId which is a part determined by the
application, usually related to the runtime environment. Spring Cloud Vault
Config supports IP address, Mac address and static
UserId’s (e.g. supplied via System properties). The IP and Mac address are
represented as Hex-encoded SHA256 hash.
Using IP addresses:
1
export IP_ADDRESS=`echo -n 192.168.99.1 | sha256sum`
Using MAC address:
1
export $MAC_ADDRESS=`echo -n ABCDEFGH | sha256sum`
The following settings and properties are available from the CAS configuration catalog:
spring.cloud.vault.app-id.app-id-path=app-id
Mount path of the AppId authentication backend. |
spring.cloud.vault.app-id.network-interface=
Network interface hint for the "MAC_ADDRESS" UserId mechanism. |
spring.cloud.vault.app-id.user-id=MAC_ADDRESS
UserId mechanism. Can be either "MAC_ADDRESS", "IP_ADDRESS", a string or a class name. |
spring.cloud.vault.authentication=
|
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
Kubernetes Authentication
Kubernetes authentication mechanism allows to authenticate with Vault using a Kubernetes Service Account Token. The authentication is role based and the role is bound to a service account name and a namespace.
The following settings and properties are available from the CAS configuration catalog:
spring.cloud.vault.authentication=
|
spring.cloud.vault.kubernetes.kubernetes-path=kubernetes
Mount path of the Kubernetes authentication backend. |
spring.cloud.vault.kubernetes.role=
Name of the role against which the login is being attempted. |
spring.cloud.vault.kubernetes.service-account-token-file=/var/run/secrets/kubernetes.io/serviceaccount/token
Path to the service account token file. |
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
Generic Backend v1
The following settings and properties are available from the CAS configuration catalog:
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
KV Backend v2
The following settings and properties are available from the CAS configuration catalog:
spring.cloud.vault.kv.application-name=application
Application name to be used for the context. |
spring.cloud.vault.kv.backend=secret
Name of the default backend. |
spring.cloud.vault.kv.backend-version=2
Key-Value backend version. Currently supported versions are:
Deprecation status is |
spring.cloud.vault.kv.default-context=application
Name of the default context. |
spring.cloud.vault.kv.enabled=true
Enable the kev-value backend. |
spring.cloud.vault.kv.profile-separator=/
Profile-separator to combine application name and profile. |
spring.cloud.vault.kv.profiles=
List of active profiles. @since 3.0 |
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
MongoDb
Allow the CAS Spring Cloud configuration server to load settings from a MongoDb instance.
The following settings and properties are available from the CAS configuration catalog:
cas.spring.cloud.mongo.uri=
Mongodb URI. |
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
Azure KeyVault Secrets
Allow the CAS Spring Cloud configuration server to load settings from Microsoft Azure’s KeyVault instance.
The following settings and properties are available from the CAS configuration catalog:
azure.keyvault.allow-telemetry=
|
azure.keyvault.case-sensitive-keys=
Defines the constant for the property that enables/disables case sensitive keys. |
azure.keyvault.certificate-password=
|
azure.keyvault.certificate-path=
|
azure.keyvault.client-id=
|
azure.keyvault.client-key=
|
azure.keyvault.enabled=
|
azure.keyvault.order=
The constant used to define the order of the key vaults you are delivering (comma delimited, e.g 'my-vault, my-vault-2'). |
azure.keyvault.refresh-interval=
|
azure.keyvault.secret-keys=
|
azure.keyvault.tenant-id=
|
azure.keyvault.uri=
|
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
ZooKeeper
Allow the CAS Spring Cloud configuration server to load settings from an Apache ZooKeeper instance.
The following settings and properties are available from the CAS configuration catalog:
spring.cloud.zookeeper.base-sleep-time-ms=50
Initial amount of time to wait between retries. |
spring.cloud.zookeeper.block-until-connected-unit=
The unit of time related to blocking on connection to Zookeeper. |
spring.cloud.zookeeper.block-until-connected-wait=10
Wait time to block on connection to Zookeeper. |
spring.cloud.zookeeper.config.default-context=application
The name of the default context. |
spring.cloud.zookeeper.config.enabled=true
|
spring.cloud.zookeeper.config.fail-fast=true
Throw exceptions during config lookup if true, otherwise, log warnings. |
spring.cloud.zookeeper.config.name=
Alternative to spring.application.name to use in looking up values in zookeeper. |
spring.cloud.zookeeper.config.profile-separator=,
Separator for profile appended to the application name. |
spring.cloud.zookeeper.config.root=config
Root folder where the configuration for Zookeeper is kept. |
spring.cloud.zookeeper.connect-string=localhost:2181
Connection string to the Zookeeper cluster. |
spring.cloud.zookeeper.connection-timeout=
The configured connection timeout in milliseconds. |
spring.cloud.zookeeper.enabled=true
Is Zookeeper enabled. |
spring.cloud.zookeeper.max-retries=10
Max number of times to retry. |
spring.cloud.zookeeper.max-sleep-ms=500
Max time in ms to sleep on each retry. |
spring.cloud.zookeeper.session-timeout=
The configured/negotiated session timeout in milliseconds. Please refer to Curator's Tech Note 14 to understand how Curator implements connection sessions. @see Curator's Tech Note 14 |
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
Amazon Secrets Manager
The following settings and properties are available from the CAS configuration catalog:
cas.spring.cloud.aws.secrets-manager.credential-access-key=
Use access-key provided by AWS to authenticate. |
cas.spring.cloud.aws.secrets-manager.credential-secret-key=
Use secret key provided by AWS to authenticate. |
cas.spring.cloud.aws.secrets-manager.endpoint=
AWS custom endpoint. |
cas.spring.cloud.aws.secrets-manager.region=
AWS region used. |
cas.spring.cloud.aws.secrets-manager.client-execution-timeout=10000
Client execution timeout. This settings supports the
|
cas.spring.cloud.aws.secrets-manager.connection-timeout=5000
Connection timeout. This settings supports the
|
cas.spring.cloud.aws.secrets-manager.local-address=
Local address. |
cas.spring.cloud.aws.secrets-manager.max-connections=10
Maximum connections setting. |
cas.spring.cloud.aws.secrets-manager.profile-name=
Profile name to use. |
cas.spring.cloud.aws.secrets-manager.profile-path=
Profile path. |
cas.spring.cloud.aws.secrets-manager.proxy-host=
Optionally specifies the proxy host to connect through. |
cas.spring.cloud.aws.secrets-manager.proxy-password=
Optionally specifies the proxy password to connect through. |
cas.spring.cloud.aws.secrets-manager.proxy-username=
Optionally specifies the proxy username to connect through. |
cas.spring.cloud.aws.secrets-manager.retry-mode=STANDARD
Outline the requested retry mode. Accepted values are |
cas.spring.cloud.aws.secrets-manager.socket-timeout=5000
Socket timeout. This settings supports the
|
cas.spring.cloud.aws.secrets-manager.use-reaper=false
Flag that indicates whether to use reaper. |
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
Amazon Parameter Store
The following settings and properties are available from the CAS configuration catalog:
cas.spring.cloud.aws.ssm.credential-access-key=
Use access-key provided by AWS to authenticate. |
cas.spring.cloud.aws.ssm.credential-secret-key=
Use secret key provided by AWS to authenticate. |
cas.spring.cloud.aws.ssm.endpoint=
AWS custom endpoint. |
cas.spring.cloud.aws.ssm.region=
AWS region used. |
cas.spring.cloud.aws.ssm.client-execution-timeout=10000
Client execution timeout. This settings supports the
|
cas.spring.cloud.aws.ssm.connection-timeout=5000
Connection timeout. This settings supports the
|
cas.spring.cloud.aws.ssm.local-address=
Local address. |
cas.spring.cloud.aws.ssm.max-connections=10
Maximum connections setting. |
cas.spring.cloud.aws.ssm.profile-name=
Profile name to use. |
cas.spring.cloud.aws.ssm.profile-path=
Profile path. |
cas.spring.cloud.aws.ssm.proxy-host=
Optionally specifies the proxy host to connect through. |
cas.spring.cloud.aws.ssm.proxy-password=
Optionally specifies the proxy password to connect through. |
cas.spring.cloud.aws.ssm.proxy-username=
Optionally specifies the proxy username to connect through. |
cas.spring.cloud.aws.ssm.retry-mode=STANDARD
Outline the requested retry mode. Accepted values are |
cas.spring.cloud.aws.ssm.socket-timeout=5000
Socket timeout. This settings supports the
|
cas.spring.cloud.aws.ssm.use-reaper=false
Flag that indicates whether to use reaper. |
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
Amazon S3
The following settings and properties are available from the CAS configuration catalog:
cas.spring.cloud.aws.s3.credential-access-key=
Use access-key provided by AWS to authenticate. |
cas.spring.cloud.aws.s3.credential-secret-key=
Use secret key provided by AWS to authenticate. |
cas.spring.cloud.aws.s3.endpoint=
AWS custom endpoint. |
cas.spring.cloud.aws.s3.region=
AWS region used. |
cas.spring.cloud.aws.s3.bucket-name=
Bucket name that holds the settings. |
cas.spring.cloud.aws.s3.client-execution-timeout=10000
Client execution timeout. This settings supports the
|
cas.spring.cloud.aws.s3.connection-timeout=5000
Connection timeout. This settings supports the
|
cas.spring.cloud.aws.s3.local-address=
Local address. |
cas.spring.cloud.aws.s3.max-connections=10
Maximum connections setting. |
cas.spring.cloud.aws.s3.profile-name=
Profile name to use. |
cas.spring.cloud.aws.s3.profile-path=
Profile path. |
cas.spring.cloud.aws.s3.proxy-host=
Optionally specifies the proxy host to connect through. |
cas.spring.cloud.aws.s3.proxy-password=
Optionally specifies the proxy password to connect through. |
cas.spring.cloud.aws.s3.proxy-username=
Optionally specifies the proxy username to connect through. |
cas.spring.cloud.aws.s3.retry-mode=STANDARD
Outline the requested retry mode. Accepted values are |
cas.spring.cloud.aws.s3.socket-timeout=5000
Socket timeout. This settings supports the
|
cas.spring.cloud.aws.s3.use-reaper=false
Flag that indicates whether to use reaper. |
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
DynamoDb
The following settings and properties are available from the CAS configuration catalog:
cas.spring.cloud.dynamo-db.credential-access-key=
Use access-key provided by AWS to authenticate. |
cas.spring.cloud.dynamo-db.credential-secret-key=
Use secret key provided by AWS to authenticate. |
cas.spring.cloud.dynamo-db.endpoint=
AWS custom endpoint. |
cas.spring.cloud.dynamo-db.region=
AWS region used. |
cas.spring.cloud.dynamo-db.billing-mode=PROVISIONED
Billing mode specifies how you are charged for read and write throughput and how you manage capacity. Available values are as follows:
|
cas.spring.cloud.dynamo-db.client-execution-timeout=10000
Client execution timeout. This settings supports the
|
cas.spring.cloud.dynamo-db.connection-timeout=5000
Connection timeout. This settings supports the
|
cas.spring.cloud.dynamo-db.drop-tables-on-startup=false
Flag that indicates whether to drop tables on start up. |
cas.spring.cloud.dynamo-db.local-address=
Local address. |
cas.spring.cloud.dynamo-db.local-instance=false
Indicates that the database instance is local to the deployment that does not require or use any credentials or other configuration other than host and region. This is mostly used during development and testing. |
cas.spring.cloud.dynamo-db.max-connections=10
Maximum connections setting. |
cas.spring.cloud.dynamo-db.prevent-table-creation-on-startup=false
Flag that indicates whether to prevent CAS from creating tables. |
cas.spring.cloud.dynamo-db.profile-name=
Profile name to use. |
cas.spring.cloud.dynamo-db.profile-path=
Profile path. |
cas.spring.cloud.dynamo-db.proxy-host=
Optionally specifies the proxy host to connect through. |
cas.spring.cloud.dynamo-db.proxy-password=
Optionally specifies the proxy password to connect through. |
cas.spring.cloud.dynamo-db.proxy-username=
Optionally specifies the proxy username to connect through. |
cas.spring.cloud.dynamo-db.read-capacity=10
Read capacity. |
cas.spring.cloud.dynamo-db.retry-mode=STANDARD
Outline the requested retry mode. Accepted values are |
cas.spring.cloud.dynamo-db.socket-timeout=5000
Socket timeout. This settings supports the
|
cas.spring.cloud.dynamo-db.time-offset=0
Time offset. |
cas.spring.cloud.dynamo-db.use-reaper=false
Flag that indicates whether to use reaper. |
cas.spring.cloud.dynamo-db.write-capacity=10
Write capacity. |
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
JDBC
Allow the CAS Spring Cloud configuration server to load settings from a RDBMS instance.
The following settings and properties are available from the CAS configuration catalog:
cas.spring.cloud.jdbc.driver-class=
Driver class name. |
cas.spring.cloud.jdbc.password=
Database password. |
cas.spring.cloud.jdbc.sql=
SQL statement. |
cas.spring.cloud.jdbc.url=
Database url. |
cas.spring.cloud.jdbc.user=
Database user. |
Control global properties that are relevant to Hibernate, when CAS attempts to employ and utilize database resources, connections and queries.
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
REST
Allow the CAS Spring Cloud configuration server to load settings from a REST API.
The following settings and properties are available from the CAS configuration catalog:
cas.spring.cloud.rest.url=
The endpoint URL to contact and retrieve attributes. |
cas.spring.cloud.rest.basic-auth-password=
If REST endpoint is protected via basic authentication, specify the password for authentication. |
cas.spring.cloud.rest.basic-auth-username=
If REST endpoint is protected via basic authentication, specify the username for authentication. |
cas.spring.cloud.rest.headers=
Headers, defined as a Map, to include in the request when making the REST call. Will overwrite any header that CAS is pre-defined to send and include in the request. Key in the map should be the header name and the value in the map should be the header value. |
cas.spring.cloud.rest.method=GET
HTTP method to use when contacting the rest endpoint. Examples include |
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
Configuration Security
To learn more about how sensitive CAS settings can be secured, please review this guide.